今天要來複習 GitHub Copilot 的 Prompt Engineering~

筆者這次把第二天的內容整理成一篇實戰筆記，重點不是講一堆高大上名詞，而是要回答一個很務實的問題：為什麼你覺得 AI 不好用，很多時候其實不是它廢，是我們提示沒拆好、上下文沒給好、讓它沒辦法通靈。

如果你平常會用 GitHub Copilot 寫程式、改程式、產假資料，甚至想叫它幫你自動化一些雜工，這篇對你很有用。尤其是像筆者這種，常常要備課、翻教材、改範例檔的人，Prompt 寫得好，真的能為自己省下不少的時間啊~

原本以為 Prompt Engineering 就是「把話講清楚」而已，結果實際用下去才發現，沒那麼簡單。你講太少，它很難通靈；你講太多，它又被 token 吃爆；你講得不精準，它就給你做一半、漏一半。這種感覺很像帶新人，講太籠統會出事，講太細又怕他抄作業，真的是工程師的日常縮影啊,像筆者常講的一樣, 用Coding Agent很像再帶一個超強的菜鳥工程師。

🧭 4S 原則
4S，也就是 Single、Specific、Short、Surround。這套不只適用 GitHub Copilot，老實說你今天拿去跟其他大語言模型溝通，也幾乎都通用。所謂一法通、萬法通。

Single: 一次只做一件事
盡量讓 AI 專心處理單一任務，例如「寫一個計算用的 function」，不要同時叫它驗證輸入、產報表、順便幫你拯救人生。

Specific:講清楚，明確定義
像是回傳什麼、輸入格式、要不要處理例外、要不要包含 speaker notes，這些不講清楚，它就是靠猜。猜對算你賺到，猜錯也不能全怪它。

Short:精簡，不要廢話太多
Prompt 不是作文比賽。像 I need you to... 這種鋪陳，很多時候根本可以省掉。短而準，通常更有效率。

Surround: 上下文要給夠
你開著哪些檔案、檔名是否有意義、聊天紀錄有沒有歪樓，這些都會影響模型的推論。上下文有料，它才不會亂飄。

筆者自己的白話版總結就是：一題一解、描述要仔細、廢話要省、脈絡要齊。

🧪 Learning Approaches：Zero-shot、One-shot、Few-shot 怎麼用？
接著是很常見的 learning approach，也就是 Zero-shot、One-shot、Few-shot。這個概念筆者覺得在「產生假資料」的場景特別有感，實務上非常實用。

如果你什麼範例都不給，只跟它說你要幹嘛，那就是 Zero-shot。可以用，但模型通常比較容易抓不到你的意圖；給一筆範例，是 One-shot；給兩到三筆以上，通常就進入 Few-shot，命中率會明顯提高。

筆者的 Few-shot 小經驗
如果你要它產生五筆假資料，卻只給一筆範例，它很可能五筆長得像複製貼上，整個超整齊，整齊到有點可怕 😅
像身高、體重、成績這種資料，筆者通常會至少給 2~3 筆範例，讓它知道你要的是「有規律但不要一模一樣」，不然你就會得到很假的假資料。

📚 GitHub 官方最佳做法：看起來差不多，但實作眉角更多
筆者後來也去翻了 GitHub 官方文件，整理起來大概有八點，跟前面的 4S 很像，但更偏實戰。像是先 general 再 specific、提供 sample、打開相關程式當上下文、清掉歪樓的聊天紀錄等等。

拆解任務，是魔王關解法
很多人覺得大語言模型難用，其實常常是因為任務沒拆。你一次叫它完成整個專案，它當然容易飄。拆成小段、小功能、小步驟，成功率會高很多。

避免代名詞，少一點腦補空間
不要一直寫「這個」、「那個」、「它」。能寫 function name、file name、library name 就直接寫。少一點模糊，多一點精準。

迭代很重要
Prompt 不是一發入魂。它比較像敏捷開發，做了、看結果、微調、再做。沒想到這套思維也套到 Prompt 上，其實有時候，AI根本就是敏捷的最佳實踐，因為在不斷的迭代，而且你還看不到盡頭

好命名不是龜毛，是 AI 友善
變數名、函式名、檔名如果亂取成 a、b、test1，AI 也很難幫你。你在整它，其實最後常常是整到自己。

🎯 這次示範的兩個 Demo：一個改 ASP，一個翻 PPT
筆者這次準備了兩個範例。第一個很小，拿第一天用過的 ASP 檔來做 Prompt 精煉；第二個比較有感，是拿英文 PowerPoint 翻成繁體中文 PowerPoint。實作請參考完整版影片

完整版影片

✅ 筆者的小結：Prompt 工程不是玄學，是工程基本功
整理一下今天的重點，筆者覺得最值得帶走的有這幾個：

4S 原則
Single、Specific、Short、Surround，這個要內化成自己的AI心法，拿去跟其他 LLM 溝通也很好用。

Few-shot 很有感
尤其在產假資料時，別太省範例。給 2~3 筆以上，通常會比只給 1 筆穩很多。

任務要拆，歷史要清
大任務拆小步骤、歪樓聊天要清掉，這兩個看似小事，實際上超關鍵。

理解工具邊界
AI 很能幫忙，但不是萬能精靈。你如果搞錯它在做什麼，體感就會從「AI 好強」瞬間變成「這啥鬼」。

老實說，筆者越用越覺得，Prompt Engineering 的本質，就是工程師本來就該有的能力——拆解問題、描述需求、控制範圍、理解系統——換一個地圖再練一次。只是現在合作對象從人變成 AI，然後 AI 還很會一本正經地答錯你而已。